home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 1⁄12⁄90 / 0038-Re C++ & ObjectPasca-Jan90 < prev    next >
Encoding:
Text File  |  1990-01-12  |  3.2 KB  |  88 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  LEFFLER1     to RODSETH.R
  2.  
  3. Item    6564123                         11-Jan-90        10:32
  4.  
  5. From:   ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. To:     CPLUS.APPLE$                    C++ Interest List--Apple Employees
  8.         UK0310                          Paul G Smith
  9.         CPLUS.DEV$                      C++ Interest List--Developers
  10.  
  11. Sub:    RE>C++ & ObjectPascal eff
  12.  
  13. Attn: C++ Apple
  14. Attn: Paul G Smith
  15. Attn: C++ Public
  16. SentBy: Larry Rosenstein
  17. Date   1/11/90
  18. Subject    RE>C++ & ObjectPascal effic
  19. From   Larry Rosenstein
  20. To C++ Apple
  21.    Paul G Smith
  22.    C++ Public
  23.  
  24.          Reply to:   RE>C++ & ObjectPascal efficien
  25. In Object Pascal a method call takes 4 bytes.  The same is true of a C++
  26. method call that involves a PascalObject.
  27.  
  28. In other C++ method calls, however, the call is expanded inline.  This means
  29. that dispatching is very fast.
  30.  
  31. It also means that the code to index into the dispatch table and adjust the
  32. object pointer (in the case of multiple inheritance) is duplicated for each
  33. method call.  Each method calls can take as much as 20 bytes.
  34.  
  35. You can reduce this by using SingleObjects, which uses the C++ 1.2 dispatching
  36. scheme that doesn't allow for multiple inheritance.  The number of bytes is
  37. still going to be larger than 4.
  38.  
  39. There's also potential inefficiencies depending on how you use C++.  If you
  40. use stack based objects, then there's extra overhead for constructors and
  41. destructors that one might not realize at first.
  42.  
  43. Just declaring a variable:
  44.            TMyObject anObj;
  45. results in a constructor call, and a destructor call.  If the destructor is
  46. virtual, then you have the virtual call overhead.
  47.  
  48. If you next do:
  49.             anObj = Func(...);
  50. then the result of Func is assigned to anObj.  In Object Pascal, this would
  51. assign one handle to another.  With a stack based C++ object, the object
  52. returned by Func is copied into anObj.
  53.  
  54. The default is to assign each field of the object individually, but any class
  55. can override the assignment operator it is chooses.  If a field is itself an
  56. object (not an object pointer or reference) then the rule is again applied.
  57.  
  58. In the above case, you can eliminate the first contructor by constructing and
  59. initializing the object in 1 step:
  60.            TMyObject anObj = Func(...);
  61.  
  62. Even better is:
  63.           TMyObject anObj(...);
  64. where you pass initialization data to the constructor.  This eliminated the
  65. copy entirely.
  66.  
  67. Objects are also copied if you pass an object by value or return an object
  68. from a function call.  If the parameter (or return result) is declared as
  69. "TMyObject" then a copy is done; if it is declared as "const TMyObject&" then
  70. the copy isn't done.  Sometimes you want to copy objects, but in many cases it
  71. isn't necessary.
  72.  
  73. Finally, it is true that C++ generates bad code in some cases.  Part of this
  74. is a lack of optimizations in MPW C and part is due to the fact that CFront
  75. generates excessive C code.  I think the nature of the compilation process
  76. (where CFront generates C code that is then compiled) makes it more difficult
  77. to produce high quality code.
  78.  
  79. Before placing all the blame on the compilers, it is important to examine the
  80. source code for inefficiencies.
  81.  
  82. Larry Rosenstein
  83.  
  84.  
  85.  
  86.  
  87.  
  88.